Would you mind opening an issue or point to some existing issue for the behavior you're encountering? We can discuss possible fixes there.

I think there is a bug in _export() on L157, where the code assumes the connection will succeed, and so the retry loop here is never executed. However the raised exception should be ultimately caught here

If you just want the logs to go away, you can set a filter on the opentelemetry.sdk._shared_internal logger or disable it

Yea so the issue for me was that the logger logged the entire error trace to the std.out, which totally makes sense given the code that you shared.
So my goal was to still get to know when something fails and not just disable the logger, as I feel like the otlp_exporters should handle this internally.

On top of that I would like to generally comment that doing a retry over a try-except in _export() feels kinda odd to me.
Thanks for taking your time to look into this! :)

Do you still think I should open an issue for that generally?

@aabmass, from what I understand, this is basically when the HTTP endpoint is not available and the urllib call is unable to complete the request, and this outputs the full stacktrace of urllib with the connection refused error.

I think an appropriate fix could be in export fix the retry logic under a try/catch, like:

try:
  resp = self._export(serialized_data, remaining_time)
except Exception as exc:
  is_retryable = True
else:
  is_retryable = _is_retryable(resp)

and use that variable in the if at L183. Maybe needs more adjustments. wdyt @aabmass @DylanRussell ?

yeah makes sense to me @pafi-code

So just to be clear: You want me to implement the changes regarding supporting the retry loop in case the request is not successful?

@pafi-code if you are open to do that would be good, if not please lmk so I can file a PR, but I believe the correct approach is to fix the bug of the request not getting into the retry loop

PR is updated. Two questions:

1. Are you fine with me excepting Exceptions in general or should I only handle ConnectionError? I assume ConnectionError is preferable.
2. Are you fine with the log message in case of time out or max retries?

1. @pafi-code let's catch requests.exceptions.RequestException, wdyt?
2. My first thought on this fix was:

        try:
            resp = self._export(serialized_data, remaining_time)
            if resp.ok:
                return SpanExportResult.SUCCESS
        except requests.exceptions.RequestException as exc:
            reason = str(exc)
            retryable = True
            status_code = None
        else:
            retryable = _is_retryable(resp)
            status_code = resp.status_code
            reason = resp.reason

        # Compute jittered exponential backoff
        backoff = (2 ** retry_num) * random.uniform(0.8, 1.2)
        remaining_time = deadline - time()

        if (
            not retryable
            or retry_num + 1 == _MAX_RETRYS
            or backoff > remaining_time
            or self._shutdown
        ):
            if status_code is None:
                _logger.error("Failed to export span batch: %s", reason)
            else:
                _logger.error(
                    "Failed to export span batch code: %s, reason: %s",
                    status_code,
                    reason,
                )
            return SpanExportResult.FAILURE

        _logger.warning(
            "Transient error %s encountered while exporting span batch, retrying in %.2fs.",
            reason,
            backoff,
        )

        if is_shutdown_in_progress.wait(backoff):
            _logger.warning("Shutdown in progress, aborting retry.")
            break

    return SpanExportResult.FAILURE